This disclosure relates to computer software applications, and more particularly web-based computer software applications known as web services.
Web services are web-based computer software applications which interact with other applications, such as other web services or client applications. Web services may be made publicly available or may be deployed in private environments, such as within a private organization to enable divisions and/or subsidiaries to exchange data. Applications may search for a description of a service and, once an appropriate service is found, may interact with it, such as to complete a fee-based transaction.
Communication with a web service is accomplished via messages. Specifically, in order to invoke a function provided by a web service, an application typically transmits a “request” message, in a predefined format specified by the web service, to an appropriate endpoint. Upon processing information included in the message, the web service may transmit a “response” message to the application, which also has a predefined format specified by the web service.
A web service description document defines characteristics of a web service, including the functions or operations it provides, the format of request and response messages, the communication protocols it employs, and other features (including behaviors and rules, for example). Thus, a web service description document provides a machine-readable description (otherwise referred to as a schema) of a web service to an application. Web service description documents may be developed, for example, in the web service description language (WSDL), the simple object access protocol (SOAP) Service Description Language (SSDL), or any other suitable description language.
The WSDL is an extensible markup language (XML) based language used for describing the functionality offered by a web service. A WSDL description of a web service (otherwise referred to as a WSDL document) therefore provides a machine-readable definition of the format of a particular message in the form of an XML Schema. The XML Schema may be incorporated within the WSDL document itself, or may be defined by a separate XML Schema Document (XSD).
A web service description document may also define a binding, or communication protocol, used by the web service to receive and/or transmit messages. For example, a description document may specify that a web service employs the SOAP, Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), or any other communication protocol.
Thus, by way of example, WSDL can be used in combination with SOAP and an XML Schema to provide web services over the Internet. A client application connecting to a web service can read the WSDL document to determine what operations are available, and any special data types used by the web service are described in the form of an XML Schema (which may or may not be embedded in the WSDL document). The client application can then use SOAP to actually call one of the operations listed in the WSDL document using XML or HTTP.
The schemas used (in WSDL and XSD documents, for example) to describe a web service may be very large and complex (due to large and complex inter-related data records being employed for example). In practice, each client may only employ subset of the possible data, and therefore only use a subset of the message schema. Also, different clients may employ different subsets. Thus, when clients want to use a web service, they must typically use a message schema which is far more complex than is actually required for their individual requirements.
It is known to provide a software tool that allows a client customer to “tailor” or edit the message schema. Essentially, WSDL & XSD documents/files can be edited to remove content that a user is not interested in using. The tailored/edited documents/files can then be used instead of the original WSDL & XSD documents/files, so that the client has exactly the required interface and nothing irrelevant.
A screenshot of such a conventional software tool for editing a message schema is shown in FIG. 1. Using the software tool, a user first selects the web service operations that are required (none are included by default). This is a simple task. The software tool then calculates the subset of the full message schema required to support those operations. If required, the user may then undertake the additional task of trimming out unwanted portions of the tailored message schema. This is somewhat complex if the user is aiming for a small subset. It will be appreciated that the conventional software tool assists a user with parts of the task that can be automated, but there is still a lot of possible message data that the user has to think about.
A known alternative approach to generating a tailored message schema is to start with an empty or minimal message schema and have a user add only the required content. However, this places onerous technical requirements on the user, especially for cases where the user wants to add more than a few message elements.